xargs: treat whitespace-only input as no argument (fixes #771) - #819

Fixes #771.

Problem

When a filename (or any input) given to xargs consists solely of an ASCII space, uu xargs passes an empty-string argument to the child process:

$ echo -n " " > a.txt
$ ./target/debug/xargs -a a.txt ls
ls: cannot access ''

GNU xargs instead treats the lone space as a delimiter and runs the child with no extra arguments:

$ xargs -a a.txt ls
<lists the cwd, exit 0>

The same discrepancy occurs for any whitespace-only input (space, tab, newline, runs of them) on both stdin and -a.

Root cause

In src/xargs/mod.rs, the WhitespaceDelimitedArgumentReader::next loop returns Ok(None) at EOF only when no bytes have been read at all (i == 0). Input that was consumed but consisted purely of delimiters left result empty while i > 0, so the loop fell through and emitted a zero-length Argument. xargs then passed that empty string to the child.

Fix

At EOF, return Ok(None) whenever result is empty, not only when i == 0. This makes whitespace-only input behave exactly like empty input (delimiters separate arguments; a run of delimiters with no content between them yields no argument), matching GNU xargs. The i == 0 case is subsumed since no bytes read implies result is empty.

Behavior of normal tokenization (leading/trailing/multiple delimiters around real content, quoted/escaped args) is unchanged.

Test

Added xargs_whitespace_only_input covering space, tab, mixed whitespace, --no-run-if-empty, and the -a repro from the issue (asserting the child receives zero xargs-provided arguments). All existing xargs tests still pass.

cargo test          # 226 + 28 (xargs) tests, all pass
cargo fmt --check   # clean
cargo clippy --all-targets -- -D warnings   # clean

The acceptance criterion is GNU xargs behavior: whitespace-only input yields no argument.

Developed with AI assistance and reviewed by the contributor.